There are plenty of established protocols for data exchange and communication. Some protocols are adapted to specific characteristics of the employed communication channel, in that the protocol definition takes into account—amongst others—data rate of the channel, whether the channel is shared or not, channel length, physical implementation (e.g. wire bound or wire-less transmission), radio frequency bandwidth, etc. Protocols and definitions for local wire-less communication include for example EnOcean™, Dash7™, OneNet™, ANT™, Bluetooth™, Z-Wave™, Zigbee™, WirelessHart™, 6LoWPAN™, MiWi™, IEEE 802.15.4, IEEE 802.11 (WiFi), and others.
Usually, a protocol defines some unit of data that represents the minimum of information that is transmitted over a respective channel. Such units are as denoted “packet”, “telegram”, or “frame”. In the context of the present disclosure, the term “frame” should denote such a unit of information as defined by the respective protocol under consideration. Further, it is common to provide a frame with addressing and/or routing information so that any entity that receives the frame is in principle able to determine whether the received frame is addressed to this entity.
Besides the implementation of the protocols, there is also a broad range of standard hardware for facilitating actual communication. For example, modules are available for carrying out communication over one or more protocols, so that there is no need for repeatedly implementing protocol and communication capabilities in a given application. Said modules usually feature some kind of inter-connectivity, so that cooperation with the application is facilitated. In other words, one may concentrate on the application as such by relying on standardized modules for effecting communication. Thus, there is no need for explicitly including the protocol and communication functionalities in the application as such.
Although the employment of standardized protocols and corresponding hardware—in the form of the aforementioned modules or as built-in functions of integrated circuits (ICs)—provides advantages with respect to simplicity, reliability, and cost, the use of standard “equipment”, however, implies the respective limitations and restrictions from the chosen standard solution. As a consequence, a chosen protocol may, on the one hand, substantially facilitate implementation (low circuit complexity, high reliability, low unit cost, etc.), but, on the other hand, impose at the same time serious restrictions.
Amongst others, standard protocols may define a strict sequence with which data exchange needs to be carried out. For example, the IEEE 802.15.4 standard (and related implementations) provides a so-called request command frame for polling for pending data. In this way, a receiving entity (device) can be powered down or in an idle state, whilst a transmitting entity (device) generates or accumulates data to be transmitted to the receiving entity. This pending data can then be polled by the receiving entity by transmitting the request command frame to the transmitting entity. As a consequence, the receiving entity can decide on its own when to receive any pending date and, therefore, does not need to be “on line” all the time. On the contrary, the receiving device can save power when it decides that the reception of any pending data is not necessary at the moment.
At the same time, distributed data acquisition is becoming more and more popular in various environments, such as scientific research, industrial equipment, network management, facility management, and the like. With the advent of the so-called “internet of things”, distributed stand-alone devices or applications get on-line, so as to gather local information, possibly process it, and forward or transmit the acquired data to some central entity for further processing and/or evaluation.
For example, a sensor device measures usage of a resource in a facility (e.g. water, electricity, soap, etc.). The acquired information may then be collected by some sort of equipment that communicates to the individual sensor device(s). It is desirable to have all such equipment operating reliable, manufactured at low cost, and consuming low power (e.g. the latter allows battery-powered stand-alone devices). Although the above objectives can be met by employing standard protocols and corresponding hardware, the chosen protocol may then limit the number of possible addressable devices, since the address space of the chosen protocol may not allow the definition of a sufficient number of unique address, and, with this, device identifiers.
There is therefore a need in various environments to allow an application implementation by means of standard equipment. At the same time, however, there is a need for further reducing the power consumption of the involved devices. Especially in view of distributed data acquisition equipment that is provided only with limited power resources and where maintenance (e.g. replacing or recharging batteries) is desirably reduced to a minimum. Specifically, there is a need for further improving standardized protocols and corresponding hardware with regard to power efficiency.